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Abstract 
This document describes the encryption and key management used by 
GigaBeam as part of the WiFiber(tm) family of radio link products. 


The security solution is documented in the hope that other wireless 
product development efforts will include comparable capabilities. 
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1. Introduction 


The GigaBeam WiFiber(tm) product family provides a high-speed point- 
to-point radio link. Data rates exceed 1 gigabit/second at a 
distance of about a mile. The transmission beam width is less than 
one degree, which means that attempts to intercept the signal are 
most successful when the attacker is either between the transmitter 
and receiver or the attacker is directly behind the receiver. Since 
interception is possible, some customers require confidentiality and 
integrity protection for the data on the radio link. This document 
describes the security solution designed and deployed by GigaBeam to 
provide these security services. 


The GigaBeam security solution employs: 


O AES-GCM [GCM] with a custom security protocol specified in this 
document to provide confidentiality and integrity protection of 
subscriber traffic on the radio link; 


o AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with IPsec ESP [ESP] to 
provide confidentiality and integrity protection of management 
traffic between the radio control modules; 


o AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with the IKE protocol [IKE] 
to provide confidentiality and integrity protection of key 
management traffic between the radio control modules; and 


o OAKLEY key agreement [OAKLEY] and RSA digital signatures 
[PKCS1] are used with IKE to establish keying material and to 


provide authentication. 


AES-GCM is used with the custom security protocol in a manner that is 
very similar to its use in ESP [ESP-GCM]. 
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2. GigaBeam High-Speed Radio Link Overview 


The GigaBeam high-speed radio link appears to be a fiber interface 
between two network devices. Figure 1 illustrates the connection of 
two devices that normally communicate using Gigabit Ethernet over a 
fiber optic cable. 
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Figure 1. GigaBeam Radio Link Example. 


Gigabit Ethernet traffic is encoded in 8B/10B format. The GigaBeam 
Radio Control Module (RCM) removes this coding to recover the 8-bit 
characters plus an indication of whether the character is a control 
code. The radio link frame is constructed from 224 10-bit input 
words, and a 4-way interleaved (56,50,10) Reed-Solomon Forward Error 
Correction (FEC) block is employed. Conversion of the Gigabit 
Ethernet data from 8B/10B format creates 224 bits of additional 
capacity in each frame, and another 196 bits is gained by recoding 
the 9-bit data using 64B/65B block codes. This additional 420 bits 
of capacity is used for the framing overhead required for FEC and 
link control. 
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2.1. GigaBeam Radio Link Frame Format 


The GigaBeam radio link frame fields are summarized in Figure 2, 
which also provides the length of each field in bits. 


Field Length Description 
SYNC FI Frame Synchronization Pattern (’10110111000’b) 
KEYSEL 1 Indicates which AES key was used for this frame 
PN 40 AES-GCM Packet Number 
FLAGS 28 Control bits, one bit for each 64B/65B data block 
DCC 8 Data Communications Channel 
DATA 1792 Data (28 encrypted 64B/65B code blocks) 
TAG 96 Authentication Tag 
SPARE 24 Reserved for alternative FEC algorithms 
CHECK 240 Reed-Solomon Check Words for 4 10-bit 
symbol (56,50) code 
Figure 2. GigaBeam Radio Link Frame Structure. 


Each of the fields in the GigaBeam 2240-bit radio link frame is 
described below. 
SYNC 


Synchronization field, an 11-bit Barker code. 


to 710110111000’b. 


Always set 


KEYSEL 


Key Selector -- select the appropriate key register for 
this frame. Two key registers are maintained to allow 
seamless rollover between encryption keys. 


PN Packet Number -- needed by AES-GCM; it carries the unique 
counter value for this frame. The value is incremented 
for each frame. 

FLAGS Control bits, one for each 64B/65B data block carried in 

the DATA field. If the bit is set, then the 

corresponding 64B/65B block in the DATA field contains a 

control code. This field is integrity protected by AES- 

GCM. 


DCC Data Communications Channel -- each frame carries one 
octet of the point-to-point data communications channel 
between the two radio control modules. See Section 2.2 
for more information on the DCC. 

DATA Subscriber data carried as 28 64B/65B code blocks. This 

field is encrypted and integrity protected by AES-GCM. 
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TAG The authentication tag generated by AES-GCM, truncated to 
96 bits. 

SPARE 24 bits, set to zero. 

CHECK Forward error correction check value -- 24 check symbols 


are generated by a 4-way interleaved Reed-Solomon 
(56,50,10) algorithm. FEC is always active, but 
correction can be selectively enabled. For each frame, 
FEC processing also returns the number of bit errors, the 
number of symbols in error, and whether the FEC 
processing failed for the frame. This information allows 
an estimation of the bit error rate for the link. 


2.2. Data Communications Channel 


The Data Communications Channel (DCC) field reserves eight bits in 
each 2240-bit radio link frame for use in constructing a dedicated 
point-to-point link between the two RCMs. The DCC content is 
connected to a Universal Asynchronous Receiver/Transmitter (UART) 
controller that processes the DCC bit stream to provide an 
asynchronous serial channel that is visible to the RCM operating 
system. The Point-to-Point Protocol (PPP) [PPP] is used on the 
serial channel to create a simple two-node Internet Protocol (IP) 
network. Each IP datagram is spread over a large number of radio 
link frames. This two-node IP network carries management protocols 
between the GigaBeam RCMs. 


IKE [IKE] runs on this two-node IP network to manage all 
cryptographic keying material. IPsec ESP [ESP] is used in the usual 
fashion to protect all non-IKE traffic on the data control channel. 
IPsec ESP employs AES-CBC as described in [ESP-CBC] and HMAC-SHA-1 as 
described in [ESP-HMAC]. 


3. Radio Link Processing 


The fiber interface constantly provides a stream of data encoded in 
8B/10B format. A radio link frame is constructed from 224 10-bit 
input words. Conversion of the data from 8B/10B format creates 224 
bits of additional capacity in each frame, and then recoding using 
64B/65B block codes creates another 196 bits of additional capacity. 
After encryption, the 64B/65B blocks are carried in the DATA field, 
and the control code indicator bits are carried in the FLAGS field. 
The additional capacity is used for the framing overhead. 
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Processing proceeds as follows: 
o encryption and integrity protection as described in Section 3.1; 


o forward error correction (FEC) processing as described in Section 
32s 


o scrambling as described in Section 3.3; and 
o differential encoding as described in Section 3.4. 
3.1. Encryption and Integrity Protection 


The GigaBeam RCM contains two key registers. The single-bit KEYSEL 
field indicates which of the two registers was used for the frame. 


AES-GCM [GCM] employs counter mode for encryption. Therefore, a 
unique value for each frame is needed to construct the counter. The 
counter includes a 32-bit salt value provided by IKE and a 40-bit 
packet number from the PN field in the radio link frame. The same 
counter value must not be used for more than one frame encrypted with 
the same key. The 128-bit counter block is constructed as shown in 
Figure 3. The first 96 bits of the AES counter block are called the 
Nonce in the AES-GCM algorithm description. Note that AES-GCM uses 
BLOCK values of zero and one for its own use. The values beginning 
with two are used for encrypting the radio link frame payload. 


Field Length Description 


SALT 32 Salt value generated during the IKE exchange 
MBZ1 24 These bits must be zero 

PN 40 AES-GCM Packet Number carried in PN field 
MBZ2 28 These bits must be zero 

BLOCK 4 Block counter used in AES-GCM 


Figure 3. AES Counter Block Construction. 


AES-GCM is used to protect the FLAGS and DATA fields. The FLAGS 
field is treated as authenticated header data, and it is integrity 
protected, but it is not encrypted. The DATA field is encrypted and 
authenticated. The TAG field contains the authentication tag 
generated by AES-GCM, truncated to 96 bits. 


Reception processing performs decryption and integrity checking. If 
the integrity checks fail, to maintain a continuous stream of 
traffic, the frame is replaced with K30.7 control characters. These 
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control characters are normally used to mark errors in the data 
stream. Without encryption and integrity checking, these control 
characters usually indicate 8B/10B running disparity or code errors. 


3.2. Forward Error Correction (FEC) 


The 224 10-bit data symbols that make up each radio link frame are 
grouped into 4 subframes each consisting of 56 symbols. The 
subframes are formed by symbol interleaving. A Reed-Solomon Code, 
RS (56,50), designed for 10-bit symbols is applied to each subframe. 


This Reed Solomon Code detects 6 errors and corrects 3 errors within 
each subframe. The FEC function is always active; however, it is 
possible to disable correction of the received data to support 
debugging. 


3.3. Scrambler 


The scrambler ensures that long series of one bits and long series of 
zero bits do not occur. When encryption is enabled, long series of 
common bit values is very unlikely; however, during the initial IKE 
exchange, the radio link frame payload is all zero bits. 


The scrambling polynomial is (1 + x^14 + x%*15). All words of a frame 
except the SYNC pattern are scrambled prior to transmission using 
this linear feedback shift register (LFSR). The LFSR is initialized 
to all ones at the start of each frame, prior to the first processed 
bit. Each processed input bit is added modulo 2 (i.e., an XOR) to 
the output of the x15 tap to form the output bit. 


On reception, an identical process is performed after frame 
synchronization and prior to subsequent processing to recover the 
original bit pattern. 


3.4. Differential Encoding 


The data stream is differentially encoded to avoid symbol ambiguity 
at the receiver. Since the demodulator could produce true or 
inverted data depending on the details of the radio frequency (RF) 
and intermediate frequency (IF) processing chains, differential 
encoding is used to ensure proper reception of the intended bit 
value. A zero bit is encoded as no change from the previous output 
bit, and a one bit is encoded as a change from the previous output 
bit. Thus, an output bit is the result of XORing the unencoded bit 
with the previously transmitted encoded bit. 
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On reception, a complementary operation will be performed to produce 
the decoded datastream. The bitstream is formed by XORing the 
received encoded bit and the previously received encoded bit. 


4. Key Management 


The Internet Key Exchange (IKE) is used for key management [IKE]. 


IKE has two phases. In Phase 1, two Internet Security Association 
and Key Management Protocol (ISAKMP) peers establish a secure, 
authenticated channel with which to communicate. This is called the 
ISAKMP Security Association (SA). In the GigaBeam environment, the 
Phase 1 exchange is IKE Aggressive Mode with signatures and 
certificates. The RSA signature algorithm is used. 


Phase 2 negotiates the Security Associations for the GigaBeam custom 
security protocol that protects subscriber traffic and IPsec ESP that 
protects management traffic between the GigaBeam RCMs. In the 
GigaBeam environment, the Phase 2 exchange is IKE Quick Mode, without 
perfect forward secrecy (PFS). The information exchanged along with 
Quick Mode is protected by the ISAKMP SA. That is, all payloads 
except the ISAKMP header are encrypted. A detailed description of 
Quick Mode can be found in Section 5.5 of [IKE]. 


When the Security Association is no longer needed, the ISAKMP Delete 
Payload is used to tell the peer GigaBeam device that it is being 
discarded. 


4.1. Certificates 


Each GigaBeam device generates its own public/private key pair. This 
generation is performed at the factory, and the public key is 
certified by a Certification Authority (CA) in the factory. The 
certificate includes a name of the following format: 


C=US O=GigaBeam Corporation OU=GigaBeam WiFiber (tm) 
SerialNumber=<device-model-identifier>/<device-serial-number> 


The ISAKMP Certificate Payload is used to transport certificates, and 
in the GigaBeam environment, the "X.509 Certificate - Signature" 
certificate encoding type (indicated by a value of 4) is always used. 


GigaBeam devices are always installed in pairs. At installation 
time, each one is configured with the device model identifier and 
device serial number of its peer. The device model identifier and 
device serial number of a backup device can also be provided. An 
access control check is performed when certificates are exchanged. 
The certificate subject name must match one of these configured 
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values, and the certification path must validate to a configured 
trust anchor, such as the GigaBeam Root CA, using the validation 
rules in [PKIX1]. 


4.2. Oakley Groups 


With IKE, several possible Diffie-Hellman groups are supported. 
These groups originated with the Oakley protocol and are therefore 
called "Oakley Groups". 


GigaBeam devices use group 14, which is described in Section 3 of 
[MODP]. 


4.3. Security Protocol Identifier 


The ISAKMP proposal syntax was specifically designed to allow for the 
simultaneous negotiation of multiple Phase 2 security protocol 
suites. The identifiers for the IPsec Domain of Interpretation (DOT) 
are given in [IPDOI]. 


The GigaBeam custom security protocol has been assigned the 
PROTO_GIGABEAM RADIO protocol identifier, with a value of 5. 


The PROTO_GIGABEAM_RADIO specifies the use of the GigaBeam radio link 
frame structure, which uses a single algorithm for both 
confidentiality and authentication. The following table indicates 
the algorithm values that are currently defined. 


Transform ID Value 
RESERVED 0 
GIGABEAM AES128_ GCM 1 


4.4. Keying Material 


GIGABEAM AES128_GCM requires 20 octets of keying material (called 
KEYMAT in [IKE]). The first 16 octets are the 128-bit AES key, and 
the remaining four octets are used as the salt value in the AES 
counter block. 


Presently, AES with a 128-bit key is the only encryption algorithm 


that is supported. Other encryption algorithms could be registered 
in the future. 


Housley & Corry Informational [Page 9] 


RFC 4705 GigaBeam Radio Link Encryption October 2006 


4. 


4. 


4. 


5. Identification Type Values 


The following table lists the assigned values for the Identification 
Type field found in the ISAKMP Identification Payload. 


ESERVED 
D_IPV4_ADDR 
D_FQDN 
D_USER_FQDN 
D_IPV4_ADDR_SUBNET 
D_IPV6_ADDR 
D_IPV6_ADDR_SUBNET 
D_IPV4_ADDR_RANGE 
D_IPV6_ADDR_RANGE 
D_DER_ASN1_DN 
D_DER_ASN1_GN 
D_KEY_ID 


HHHHHHHHHHHD 
FOWUODINHDUBWNHEO 


eHe 


The ID_DER_ASN1_DN will be used when negotiating security 
associations for use with the GigaBeam custom security protocol. The 
provided distinguished name must match the peer’s subject name 
provided in the X.509 certificate. 


6. Security Parameter Index 


The least significant bit of the Security Parameter Index (SPI) is 
used in the GigaBeam custom security protocol. When two GigaBeam 
custom security protocol security associations are active at the same 
time for communications in the same direction, the least significant 
bit of the SPI must be different to ensure that these active security 
associations can be distinguished by the single bit in the GigaBeam 
custom security protocol. 


7. Key Management Latency 


The IKE exchange over the DCC must complete before subscriber data 
can be exchanged in the GigaBeam radio link frame payload. Since 
each radio link frame carries a small portion of an IP datagram, many 
radio link frames carrying all zero bits must be sent and received to 
complete the IKE exchange. 


Once the initial keying material is in place, the IKE exchanges to 
establish subsequent keying material can be performed concurrent with 
the transfer of subscriber data in the radio link frame payload. The 
KEYSEL field in the radio link frame is used to indicate which keying 
material is being used. 
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The PN field in radio link frame provides a continuous indication of 
the number of frames that have been encrypted with a particular key. 
Once a threshold is exceeded, the IKE exchanges begin to establish 
the replacement keying material. Currently, the exchanges begin when 
half of the packet numbers have been used, but any threshold can be 
employed, as long as the replacement keying material is available 
before the packet counters are exhausted. 


5. Security Considerations 


The security considerations in [IKE], [OAKLEY], [PKCS1], and [ESP] 
apply to the security system defined in this document. 


Confidentiality and integrity are provided by the use of negotiated 
algorithms. AES-GCM [GCM] is used with the GigaBeam custom security 
protocol to provide confidentiality and integrity protection of 
subscriber traffic on the radio link. AES-CBC [CBC] and HMAC-SHA-1 
[HMAC] are used with IPsec ESP [ESP] to provide confidentiality and 
integrity protection of management traffic between the radio control 
modules. 


AES-GCM makes use of AES Counter mode to provide confidentiality. 
Unfortunately, it is very easy to misuse counter mode. If counter 
block values are ever used for more than one frame with the same key, 
then the same key stream will be used to encrypt both frames, and the 
confidentiality guarantees are voided. Using AES Counter mode with 
the same counter values to encrypt two plaintexts under the same key 
leaks the plaintext. The automated key management described here is 
intended to prevent this from ever happening. 


Since AES has a 128-bit block size, regardless of the mode employed, 
the ciphertext generated by AES encryption becomes distinguishable 
from random values after 2^64 blocks are encrypted with a single key. 
Since the GigaBeam radio link frame allows for up to 2^40 fixed- 
length frames in a single security association, there is no 
possibility for more than 2^64 blocks to be encrypted with one key. 


The lifetime of a particular AES key can be shorter than 2%40 frames. 
A smaller threshold can be used as a trigger to transition to the 
next key. This capability allows straightforward implementation of 
policies that require the key to be changed after a particular volume 
of traffic or a particular amount of time. 


There are fairly generic precomputation attacks against all block 
cipher modes that allow a meet-in-the-middle attack against the key. 
These attacks require the creation and searching of huge tables of 
ciphertext associated with known plaintext and known keys. Assuming 
that the memory and processor resources are available for a 
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precomputation attack, then the theoretical strength of AES Counter 
mode (and any other block cipher mode) is limited to 2%(n/2) bits, 
where n is the number of bits in the key. The use of long keys is 
the best countermeasure to precomputation attacks. The unpredictable 
nonce value in the counter block significantly increases the size of 
the table that the attacker must compute to mount a successful 
precomputation attack. 


Rekeying with Quick Mode results in new keys to protect GigaBeam 
radio link frames; however, these keys are generated from the same 
Diffie-Hellman shared secret. In order to limit the amount of data 
that would be exposed by the disclosure of this Diffie-Hellman shared 
secret or the associated Diffie-Hellman private key, implementations 
should periodically rekey using a new Phase 1 exchange. 


Diffie-Hellman exponents used in IKE Phase 1 should be erased from 
memory immediately after use. Likewise, AES and HMAC-SHA-1 keying 
material should be erased from memory when it is no longer needed. 


This security solution makes use of IKEvl [IKE]. IKEvl was selected 
over IKEv2 [IKEv2] primarily due to the availability of an 
implementation for the processing environment. The use of IKEv2 


would provide some useful capabilities, such as Diffie-Hellman group 
negotiation. These additional capabilities would not significantly 
improve the security of the overall key management solution that runs 
on the two-node IP network. 


6. IANA Considerations 
IANA has assigned one IPsec Security Protocol Identifier in 
http://www.iana.org/assignments/isakmp-registry for 
PROTO_GIGABEAM RADIO. It was assigned the value 5. 
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